1. Technical Field
The present invention relates generally to network security, and more particularly to a method and system for securing resources from untrusted scripts behind firewalls.
2. Description of the Prior Art
Presently, many computer users primarily employ Internet browsing applications (the browser) for accessing the World Wide Web (WWW, or the Web). The World Wide Web comprises all Web servers on the Internet serving static or dynamically generated Hypertext Markup Language (HTML) documents over the standard Internet protocols like Hypertext Transfer Protocol (HTTP). To access the Web, a user just points his browser to a Uniform Resource Locator (URL), which identifies resources via a representation of their primary access mechanism (e.g. their network location) rather than identifying the resource by name or by some other attributes of that resource. The URL is a subset of Uniform Resource Identifier. The Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource, which has a well-defined syntax.
Scripts in various languages have been introduced to make Web pages more interactive by manipulating HTML elements. JavaScript language is probably the most common used script language on the Web. An HTML document may embed Scripts directly or include URL references to script documents. Either way, the scripts are downloaded along with the HTML document.
Nowadays, many powerful functions have been added script languages, and the scripts can be coded to access resources from a different domain. The scripts can even issue calls over the Simple Object Access Protocol (SOAP).
SOAP is a way for a program running in one kind of operating system (such as Windows 2000) to communicate with a program in the same or another kind of an operating system (such as Linux) by using the World Wide Web's Hypertext Transfer Protocol (HTTP) and its Extensible Markup Language (XML) as the mechanisms for information exchange. Since Web protocols are installed and available for use by all major operating system platforms, HTTP and XML provide an already at-hand solution to the problem of how the programs running under different operating systems in a network can communicate with each other. SOAP specifies exactly how to encode an HTTP header and an XML file so that a program in one computer can call a program in another computer and pass it information. It also specifies how the called program can return a response.
An advantage of SOAP is that program calls are much more likely to get through firewall servers that screen out requests other than those for known applications (through the designated port mechanism). Because HTTP requests are usually allowed through firewalls, programs using SOAP are most likely able to communicate with programs behind the firewall.
To protect internal resources behind a firewall, external untrusted scripts loaded are typically executed in a security sandbox. A security sandbox is a protected, limited environment where applications, such as scripts downloaded from the Internet, are allowed to run without risking damage to the rest of the system.
The external untrusted scripts may legitimately require access to external resources. However, permitting the scripts to access internal resources would permit the compromise of the internal resources that are usually not available to applications outside of the firewall. The security sandbox must distinguish and protect internal resources.
Several client-controlled solutions have been designed to prevent sandboxed applications loaded behind a firewall from compromising other internal resources protected behind the firewall. Sample solutions include “same source restriction”, “white-listing”, “signed scripts” and “asking the user”.
In the “same source restriction” approach, sandboxed scripts are restricted to access only resources in the domain from which they were loaded, and any script loaded from one domain into another is prevented from accessing resources in the domain into which it has been loaded. This policy has generally been successful in sandboxing JavaScript and Java applets across the Web. However, if the sandbox is unable to distinguish the common URI substring of the domain to be trusted from similar URIs of untrusted domains, then it could allow a script loaded from an indistinguishable domain to exploit firewall-protected resources. Furthermore, this technique prevents the script from accessing many legitimate external resources not provided in the same domain as the script because it prevents a script from accessing Web services and data published from any domain besides its own.
In the “white-listing” approach, a white list of trusted URIs is created from which scripts are trusted to not compromise internal resources. In addition, it is possible to release domains from the stricter same source restriction approach. A white list is a good tool for including always-trusted domains. However, on the Web, it is often a script from a relatively-untrusted domain that must be granted access to other untrusted domains, without compromising internal domains. More-complex access lists could be created to try to establish, with finer granularity, which domains are to be accessible or permitted from which other domains, but this requires extensive management which at best is quite error-prone for the end user and easily opens holes in a firewall that do not directly hurt the user who reconfigured his browser to try to access some external service but hurts the owners of other services behind the firewall.
In the “signed scripts” approach, a certain degree of additional trust may be lent to a script by having the author digitally sign it. But signed scripts approach has not really caught on as it requires certificates and it does not change the basic problem that some completely-unknown party has written a script that might now have access to internal resources.
In the “asking the user” approach, when the sandbox cannot otherwise determine whether the executing script should be permitted access to the resource, a dialog box may be raised to ask the user to grant special privileges. This is currently permitted for locally-saved scripts and signed scripts. This could be combined with the other options above such as white-listing, signed scripts, etc. But the big problem with this is that the typical browser user really does not either understand or pay the consequences if he inadvertently opens a hole in his company's firewall. Quite complex settings may be required to permit the user to allow access to desired external services without risking other resources.
Therefore, access by untrusted scripts really needs to be under the control of the stake holder, which is the resource and server owner—not the user—to determine whether a resource should be insulated from Web applications loaded from outside of the firewall. One approach is to use SOAP header for verification in SOAP protocol, as offered in the current Mozilla implementation of SOAP. SOAP messages have a distinct processing model allowing a header to be added that the recipient is required to understand and accept, which identifies the untrusted source of a script making a request. SOAP services which have not been cleared for access by untrusted scripts will reject the requests.
Unfortunately, this does not prevent SOAP messages from being sent to non-SOAP addresses, which is a critical issue that the verification cannot stand alone to guarantee that untrusted service requests are always properly rejected by services that should be firewall-protected. It may also be inconvenient to modify a SOAP service to ignore the specific verification header.
It is therefore desired to develop a new technique for securing resources from untrusted scripts behind a network firewall. The technique should allow the resource and server owner to determine whether a resource should be insulated from Web applications loaded from outside of the firewall. The technique should be robust, easy to configure. Particularly, the technique should be applicable to untrusted scripts which are capable of making SOAP calls, and it should also provide configuration of access to the resource based on a request type.